Hi @RayyanSeliya. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Codecov Report

❌ Patch coverage is 12.16216% with 65 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.14%. Comparing base (63026ce) to head (c4652dd).
⚠️ Report is 4 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3117      +/-   ##
==========================================
+ Coverage   59.91%   63.14%   +3.22%     
==========================================
  Files         150      150              
  Lines       13353    13501     +148     
==========================================
+ Hits         8001     8525     +524     
+ Misses       4416     3971     -445     
- Partials      936     1005      +69     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

/ok-to-test

Im not much of a fan of this implementation... its still "test aware" as Matej said - with those literal strings and constants. Also there has to be some better way to implement this 🤔
Maybe as a method of client Instance (in pkg/functions/client.go) ? Instance has its method "CurrentState" or "State" or "Available" or something like this?
@lkingland @matejvasek

Im not much of a fan of this implementation... its still "test aware" as Matej said - with those literal strings and constants. Also there has to be some better way to implement this 🤔 Maybe as a method of client Instance (in pkg/functions/client.go) ? Instance has its method "CurrentState" or "State" or "Available" or something like this? @lkingland @matejvasek

@gauron99 Good point about the client architecture! I checked pkg/functions/client.go and saw it already has methods like Deploy(), Build(), etc.

I'm thinking we could add:

func (c *Client) ClusterAvailable(ctx context.Context) error

Then just call it before building. Tests would naturally skip it since they use NewTestClient() with mocks.

The challenge is timing - we currently validate before creating the client (line 423 vs line 462 in cmd/deploy.go's runDeploy()). We'd need to either:

1. Create the client earlier, or
2. Make it a standalone function like functions.ValidateCluster()

Which direction makes more sense for the existing code? Don't want to refactor the way which is not feasible ..!

@lkingland @matejvasek

This one is a little tricky...
I understand the desire to validate in the CLI to "fail fast". But too much pre-validation creates a hard dependency between the CLI and the deployer.

I think it might be worth looking into placing this validation in the deployer implementation itself, returing a typed error on failure, and then capturing this error in the CLI and adding "CLI specific" help text as necessary.

Remember that it's ok if the system builds and then fails on deployment, because it should not repeat the build on a subsequent deploy (it detects the build is "fresh").

This one is a little tricky... I understand the desire to validate in the CLI to "fail fast". But too much pre-validation creates a hard dependency between the CLI and the deployer.

I think it might be worth looking into placing this validation in the deployer implementation itself, returing a typed error on failure, and then capturing this error in the CLI and adding "CLI specific" help text as necessary.

Remember that it's ok if the system builds and then fails on deployment, because it should not repeat the build on a subsequent deploy (it detects the build is "fresh").

thx for the feedback @lkingland that makes sense and sounds good to have the validation into the deployer itself with typed errors and CLI just catches those and provide a user-friendly errors ! can have a look now and ping me if any more changes needed !

@RayyanSeliya: GitHub didn't allow me to request PR reviews from the following users: take, when, some, moments, pls, a, look, have.

Note that only knative members and repo collaborators can review this PR, and authors cannot review their own PRs.

/cc @lkingland

hey @lkingland dont know why the test are failing !!

/override ?

@gauron99: /override requires failed status contexts, check run or a prowjob name to operate on.
The following unknown contexts/checkruns were given:

• ?

Only the following failed contexts/checkruns were expected:

• E2E Test (ubuntu-latest, springboot)
• EasyCLA
• On Cluster RT Test (ubuntu-latest, pack)
• style / suggester / github_actions
• style / suggester / shell
• style / suggester / yaml
• tide
• unit-tests_func_main

If you are trying to override a checkrun that has a space in it, you must put a double quote on the context.

/override "On Cluster RT Test (ubuntu-latest, pack)" "E2E Test (ubuntu-latest, springboot)"

@gauron99: Overrode contexts on behalf of gauron99: E2E Test (ubuntu-latest, springboot), On Cluster RT Test (ubuntu-latest, pack)

These fails are unrelated. Its an issue with our custom pack builder currently

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gauron99, lkingland, RayyanSeliya

The full list of commands accepted by this bot can be found here.

The pull request process is described here

These fails are unrelated. Its an issue with our custom pack builder currently

Yeah ! 👍Thx ..